Various system configurations exist in which a cluster of different nodes communicate with each other, wherein a node is an operating unit (e.g., a processor-based system), operable to provide a desired function, service, or operation, or portion thereof, and which may cooperate with other nodes to form a cluster. For example, data storage systems often include a plurality of storage devices present at different nodes of the data storage system. Such a data storage system may be implemented using a variety of storage architectures, such as a network-attached storage (NAS) environment, a storage area network (SAN), a direct-attached storage environment, and combinations thereof. Nodes of a data storage system may comprise processor-based systems, such as a file server system, a computer appliance, a computer workstation, etc. Storage devices at the different nodes may comprise disk drives, flash memory, optical memory, etc. Selected ones of the storage devices may be organized as a storage array in accordance with the storage architecture. Nodes hosting the storage devices of a storage array as well as other network-connected devices may thus comprise a cluster of nodes operable cooperatively to provide a data storage system.
In order to operate as a cluster, nodes of a cluster communicate with each other. Such communication may include various point-to-point communications (e.g., single node to single node or unicast communication) and multicast communications (e.g., single node to multiple node). Accordingly, to effectively cooperate to provide desired operation each node of a cluster may need to have the capability to communicate with any and all other nodes of the cluster. Such communication, however, may traverse unsecured links, such as public or other network links (e.g., the Internet, the public switched telephone network (PSTN), a local area network (LAN), a metropolitan area network (MAN), a wide area network (WAN), etc.). Such communications carried through such unsecured links may be susceptible to interception, eavesdropping, tampering, monitoring, sniffing, man-in-the-middle attack, relay attack, replay attack, etc.
Accordingly, various security protocols have been implemented in the past to facilitate communication between nodes of a cluster (i.e., intra-cluster communication). For example, Secure Sockets Layer (SSL) and Transport Layer Security (TLS) security protocols have been implemented by nodes of a cluster for securing intra-cluster communication. SSL and TLS are cryptographic protocols that provide communication security using asymmetric cryptography for privacy and a keyed message authentication code for message reliability. These security protocols, however, are point-to-point security protocols. That is, unique key sets are utilized with respect to each node pair. Accordingly, secure multicast communication is not provided through the use of SSL and TLS security protocols.
Although protocols have been developed which provide for securing multicast communications, such protocols heretofore have not provided sufficient security with respect to multicast communications and have not adequately accommodated dynamic association of nodes with clusters. One such protocol which has been used to provide security for communications is JGROUPS. JGROUPS provides a multicast protocol in which a “grouping” layer is added over a transport protocol. To provide security with respect to the multicast communications, JGROUPS implements its AUTH and ENCRYPT protocols. The AUTH protocol, however only provides one way authentication (i.e., only one node authenticates the other) using a single token-based authentication (e.g., password or other authentication credentials communicated over the unsecured link), thus an eavesdropper can monitor the communications and mimic the security handshake (e.g., replay attack) to establish a false authentication. The ENCRYPT protocol uses a clusterKey to encrypt all multicast communications. The clusterKey of the ENCRYPT protocol, however, is provided to any node which provides its own public key and requests the clusterKey. Accordingly, even with AUTH and ENCRYPT protocols implemented by JGROUPS, a man-in-the-middle may easily join the cluster and thus the security provided with respect to multicast communications is somewhat illusory.